Security Alerting Systems (SASs) generate alerts that signal a compromise of a computing device. The alerts are transmitted to a trusted receiver for analysis and action. An SAS can be, for example, a Host-based Intrusion Detection System (HIDS), an anti-virus engine, or any software facility that can write to a system log (syslog) or an event interface and is capable of reporting events to a remote service. In a further variation, the SAS could be a dedicated Network Intrusion Detection System (NIDS), or, in an embedded device, a logical functionality that reports physical tampering. An SAS helps detect both incipient intrusions and host compromise after the fact. An SAS also gathers essential evidence for post-breach forensics. As a main intelligence source for current Security and Information Event Management (SIEM) systems, SASs play a key role in broad IT defense strategies.
Current-generation SASs, however, lack key protections against sophisticated attackers. They do not effectively prevent discovery by an attacker of whether or not its activities have been detected. By observing host emissions on a network prior to compromise, for example, an attacker can determine if an SAS is transmitting alerts. After a host is compromised, an attacker can observe host instrumentation, e.g., a HIDS rule set, as well as logs, buffered alerts, and so forth, giving further evidence of whether the activities of the attacher are likely to have been observed.
Additionally, an attacker can undetectably suppress or tamper with alert messages in most existing SASs. Most SASs transmit alerts to a remote server on the fly. By disrupting such transmissions, an attacker can cause critical alert messages to be lost. Even a reliable transport layer (e.g., through TCP) is vulnerable. An attacker can delay alert transmission (via, e.g., a host-directed Denial of Service attack) until it fully compromises a target host and breaks off SAS communications. Furthermore, logged or buffered SAS alerts are vulnerable to deletion or modification after a host is compromised.
To understand the ramifications of message suppression, consider, for instance, a rootkit Trojan that exploits a host vulnerability to achieve a privilege escalation on an enterprise server. The privilege escalation might be detected immediately by a HIDS or anti-virus engine, resulting in logging an alert, “privilege escalation.” Yet, many rootkits today modify or remove critical logs related to the installation or running of this code. Thus, if the “privilege escalation” alert remains buffered in a log on the host, the Trojan can simply delete the alert as soon as it gains full system control. An enterprise SIEM system, then, that later collects the set of transmitted logs, will fail to observe the alert, and thus to detect the Trojan. In addition, as indicated above, on-the-fly alert transmission carries its own problems.
Thus, the abilities of an attacker to discover SAS behavior and to perform undetectable alert suppression in existing SAS systems are fundamental vulnerabilities in the chain of custody between hosts and servers. Attacks against enterprises in the shape of Advanced Persistent Threats (APTs) have recently been growing noticably in sophistication. Insecure SAS chains of custody, therefore, pose an escalating systemic vulnerability.
A need therefore exists for transmitting alert messages from a security alerting system to a monitoring server.